Release 10.1A: OpenEdge Development:
Debugging and Troubleshooting

Using the DEBUGGER system handle in application mode

This technique is useful in large applications under development where the line numbers change constantly and you want to break at specific points in your code, regardless of how the surrounding code is modified, or you want to set breakpoints in include files that appear in many different procedures. This technique is also useful when implementing a Debugger tool in application mode, where you can set a breakpoint in a called subprocedure to indicate where debugging should start. Use this technique to start the Debugger on an AppServer to debug a remote procedure. For more information, see the "Remote debugging" section.

Debugging by controlling breakpoints from the 4GL

To start the Debugger from the 4GL and control the breakpoints from the 4GL itself:

Optionally, add a DEFINE VARIABLE statement that defines a logical variable you can use to assign the return value for DEBUGGER system handle methods.
Add a DEBUGGER system handle statement that invokes the INITIATE( ) method before the point where you want to begin debugging. This initializes the Debugger but does not immediately make it visible.
Add one or more DEBUGGER system handle statements that invoke the SET-BREAK( ) method to set at least one breakpoint that occurs after the statement where you set it. The SET-BREAK( ) method that sets the breakpoint must also execute after the statement that invokes the INITIATE( ) method in Step 2.
Run the invoking procedure.

For example, in the following listing fragment, the Debugger is initialized on line 6, and the procedure stops at a breakpoint on line 15. The Debugger takes control at this point. From here, you can continue executing the invoking procedure under Debugger control, stopping at and continuing from all breakpoints, as shown:

1    DEFINE VARIABLE procname 2 AS CHARACTER EXTENT 6. 3    DEFINE VARIABLE Selection 4 AS INTEGER FORMAT "9". 5    DEFINE VARIABLE debug AS LOGICAL.         6    debug=DEBUGGER:INITIATE(). 7    /* Initialize the list of procedure names to be run */ 8    procname[1] = "custedit.p". 9    procname[2] = "custrpt.p". 10    procname[3] = "ordedit.p". 11    procname[4] = "ordrpt.p". 12    procname[5] = "itemedit.p". 13    procname[6] = "itemrpt.p".        14    debug=DEBUGGER:SET-BREAK(). * => 15    DISPLAY "S A L E S O R D E R S Y S T E M" SKIP(1) 16    WITH COLUMN 18 NO-BOX. 17     . . .

When you exit the Debugger, the 4GL interpreter continues execution from its current stopping (or breaking) point. If you exit the procedure before exiting the Debugger, the Debugger window closes and control returns to the startup environment (such as the Procedure Editor or AppBuilder).

Debugging a called subprocedure

To debug a subprocedure called from the invoking procedure:

Optionally, add a DEFINE VARIABLE statement that defines a logical variable you can use to assign the return value for DEBUGGER system handle methods.
Add a DEBUGGER system handle statement that invokes the INITIATE( ) method before the point where you want to begin debugging the called subprocedure. This initializes the Debugger but does not immediately make it visible.
Add a DEBUGGER system handle statement that invokes the SET-BREAK( ) method to set a breakpoint at the first executable line of the subprocedure you want to debug. This statement must execute after the statement that invokes the INITIATE( ) method in Step 2, but before the statement that calls the subprocedure.
Run the invoking procedure.

The following listing fragment prompts the user to enter the name (procname) of a procedure to debug (line 30). It then initializes the Debugger (line 33) and sets a breakpoint on the first executable line of procname (line 34). When the invoking procedure calls procname (line 35), procname breaks immediately on its first executable line and gives control to the Debugger. The Debugger then displays the listing for procname in the Debugger window as the current procedure, as shown:

1 DEFINE VARIABLE debug AS LOGICAL. 2 DEFINE VARIABLE procname AS CHARACTER INITIAL "". . . . 30 SET procname LABEL "Enter name of procedure to debug" DEBLANK 31 WITH SIDE-LABELS. 32 IF procname <> "" THEN DO: 33 debug = DEBUGGER:INITIATE(). 34 debug = DEBUGGER:SET-BREAK(procname). 35 RUN VALUE(procname). 36 END. . . .

Note: Using this technique, the invoking procedure becomes part of the Debugger context; thus, the invoking procedure appears on the call stack. You can set breakpoints in the invoking procedure and break into it with the Debugger. In this type of application, you might not want the invoking procedure running in the Debugger context like this. You can prevent the invoking procedure from entering the Debugger context by prepending its procedure name with an underscore (_). In this case, the Debugger ignores the invoking procedure completely, and it never appears on the call stack.

Although this is a simple example, it illustrates the basic elements required to build an OpenEdge development tool that can start debugging sessions for specified application procedures.